Remote applications are accessed by users of an end device through a network. The application can be executed remotely, or be downloaded for local execution (e.g., using Java or Citrix). During upgrades of codets in remote applications using a continuous deployment model, it is common to have a production environment with a current version of the application code (e.g., a blue environment), and a separate production environment with an updated version of the application code (e.g., a green environment). The typical process is to fully deploy a well-tested new version of code but if problems ensue the code is rolled back to a previous version. A more prudent approach is to divert a small or non-critical production traffic from the default blue environment to the green environment in order to update and verify the new codet. A small percentage of traffic can be sent to the green environment and, based on the updated results, and more or less of production traffic can be sent in a sequence of phases. Once the codet is verified to satisfaction, all application traffic can be steered to the green environment and the blue environment can be retired.
Current approaches for traffic steering or splitting between blue and green environments are performed manipulating DNS end points of an application. This approach is done by configuring the application server IP addresses for both blue and green environment in the DNS entry, and then controlling the number of application server entries to steer/split the traffic proportionally between the two environments.
While this approach will split between the environments, it is very difficult to control the percentage of traffic that is split, or to split the traffic based on some application related conditions, or based on some user or user device conditions. Typically, conditions are based on some attributes of the application traffic. When the application traffic uses HTTP or HTTPS (SSL) as the transport, the HTTP header values can be used for the conditions. However, today, there is no service or product that is readily available to conditionally split traffic based on HTTP header values between completely different application environments.
Furthermore, it is difficult to ascertain performance or functional correctness of a split for verification. After tedious configuration changes to split or steer traffic between different application environments, understanding the effect of the application changes by comparing various performance and functional metrics involves manually reviewing multiple metrics dashboards and log files.
What is needed is a robust technique to improve traffic steering to a second environment. Further, improved feedback of performance and functionality at different splits is desired.